Machine to Machine (M2M) concerns technologies that allow both wireless and wired systems to communicate with other devices. M2M is considered an integral part of the Internet of Things (IoT) and has a wide range of applications such as industrial automation, logistics, Smart Grid, Smart Cities, health, defense etc. mostly for monitoring but also for control purposes.
M2M can play an important role in Location Based Services (LBS) applications. Some M2M examples of LBS include locating assets, such as for inventory; applying rules that depend on location, such as checking that a container is not opened until it is at its destination; tracking assets for billing purposes, such as for usage-based insurance; and finding assets within a given area, such as to locate the nearest truck for an urgent pick-up
Of particular interest is wireless asset tracking, which is about knowing location information (where, status of asset, change) and taking action based on the location information (Take Action, Inform, Aid, Support). Assets can be fixed (e.g. vending system) or mobile (goods in transit).
There has been interest in location information in multiple standards bodies such as oneM2M, OMA, and 3GPP. In the following, the perspective and contribution of each standard body towards the location requirements and solutions is described.
It is intended that the oneM2M Location (LOC) Common Service Function (CSF) 102 allows Application Entities (AEs) 104 to obtain geographical location information of Nodes (e.g. mobile node) for LBS as indicated in oneM2M TS 0001. The LOC CSF 102 may interact with the location server in the underlying network. The geographical location information can include more than simply the longitude and the latitude information.
Open Mobile Alliance (OMA) API provides “Terminal location” Application Program Interface (API) for terminal location, distance, or terminal movements in relation to a circular geographic area (crossing in and out of circular area). More precisely, the “Terminal location” API supports the following operations; obtain the current terminal location; obtain the terminal distance from a given location; obtain the distance between two terminals; and manage client-specific subscriptions to periodic notifications; Manage client-specific subscriptions to area (circle) notifications; Manage client-specific subscriptions to distance notifications.
The Functional stage 2 description of Location Services (LCS) is included in TS 23.271. As indicated in clause 6 of TS 23.271, FIG. 2 “shows the general arrangement of the Location Service feature in GSM, UMTS and EPS. This illustrates, generally, the relation of LCS Clients and servers in the core network with GERAN, UTRAN and E-UTRAN Access Networks. The LCS entities within the Access Network communicate with the Core Network across the A, Gb, Iu and S1 interfaces. Communication among the Access Network LCS entities makes use of the messaging and signaling capabilities of the Access Network.”
As for the Gateway Mobile Location Center (GMLC) 302 and as indicated in clause 6.3.3 of TS 23.271, “the GMLC is the first node an external LCS client accesses in a PLMN (i.e. the Le reference point is supported by the GMLC). The GMLC may request routing information from the Home Location Register (HLR) via the Lh interface or HSS via the SLh/Lh interface. Note 1 in FIG. 2 indicates that the HSS includes both 2G-HLR and 3G-HLR functionality. After performing registration authorization, it sends positioning requests to either visited Mobile Switching Center (MSC) (2G-MSC), SGSN, MSC Server or MME and receives final location estimates from the corresponding entity via the Lg, Lgd or SLg interface.” The reference points of the GMLC are indicated in FIG. 3 (TS 29.173).
The GMLC 302 provides only location estimates, as stated above. In other words, it does not provide any other context information such as the available Radio Access Technology (RAT) or the congestion level at any of the serving nodes (e.g. MME 306).
As indicated above, the GMLC 302 sends the location request to the MME 306/SGSN 308 to inquire about the UE's location. Once done, the MME 306/SGSN 308 communicates with the UE 202 to check if it is still attached and to get its current location. The specific behaviors of MME 306 and SGSN 308 can be summarized as follows.
For E-UTRAN, the MME 306 checks if the UE 202 is detached or suspended and in either such case an error response is returned. If the UE 202 is in ECM-IDLE state, the MME 306 performs a “network triggered service request” as defined in TS 23.401 in order to establish a signalling connection with the UE 202 and assign a specific eNB. Then, the MME 306 sends a “Location Request” message to an Evolved Serving Mobile Location Center (E-SMLC). The E-SMLC 702 determines the positioning method and instigates the particular message sequence for this method, as described in clause 9.3a of TS 23.271. If the position method returns position measurements, the E-SMLC uses them to compute a location estimate. The E-SMLC 702 returns its location estimate to the MME 306 in a “Location Response” message. E-SMLC 702 in its response includes an indication whether the obtained location estimate satisfies the requested accuracy or not. If a location estimate could not be obtained, the E-SMLC 702 returns a Location Response message containing a failure cause and no location estimate. Finally, the MME 306 returns the location information, its age and obtained accuracy indication to the GMLC 302.
If the UE 202 is in idle mode, the SGSN 308 performs paging. The paging procedure is defined in TS 23.060. If no paging response is received, the SGSN 308 returns an error response to the GMLC. Otherwise, the SGSN 308 sends a “Location Request” message to the RAN 604 (UTRAN/GERAN). This message includes the type of location information requested, the requested QoS and any other location information received in paging response. Accordingly, the RAN 604 determines the positioning method and instigates the particular message sequence for this method in UTRAN Stage 2 TS 25.305 and in GERAN Stage 2 TS 43.059. The RAN 604 returns the location estimate to the SGSN 308 in a “Location Report” message. RAN 604 in its response includes an indication whether the obtained location estimate satisfies the requested accuracy or not. Finally, the SGSN 308 returns the location information, its age and obtained accuracy indication to the GMLC.
3GPP has recently defined a framework to better expose underlying 3GPP network capabilities to application/service providers, TS 23.682. In order to achieve this, 3GGP has defined a new function called a Service Capability Exposure Function (SCEF 404). This function provides a means to securely expose the services and capabilities provided by 3GPP networks. The SCEF 404 provides a means for the discovery of the exposed service capabilities. The SCEF 404 provides access to network capabilities through homogenous network application programming interfaces (e.g. Network API) defined by OMA, GSMA, and possibly other standardization bodies. The SCEF 404 abstracts the services from the underlying 3GPP network interfaces and protocols.
FIG. 4 is copied from TS 23.682. It shows a diagram of the SCEF's relationship with the applications and EPC. Although not shown in the figure, the GMLC 302 may be one of the Network Entities that can connect to the SCEF 404.
The number of Machine Type Communication (MTC) devices may be several orders of magnitude greater than “traditional” devices. Many (but not all) MTC devices will be relatively stationary and/or generate low volumes of traffic. However, these UEs will still be expected to generate the same volume of control signaling as a non-MTC UE 202. A higher volume of signaling due to an increase in the number of UEs may cause overload, independent of whether the UE 202 is used for MTC or not. Such overload can happen at the P-GW/GGSN, serving nodes (MME 306/SGSN 308), or the radio access network (RAN). Hence generic functionality for overload and congestion control is required, as illustrated in TS 23.401 and TS 23.06.
The P-GW/GGSN can detect congestion on a per Access Point Name (APN) basis and reject Packet Data Protocol (PDP) context activation requests based on either:
1. The maximum number of active PDP contexts per APN
2. The maximum rate of PDP context activations per APN
When the P-GW/GGSN rejects a PDP context activation request, the P-GW/GGSN may provide a back-off time for a specific APN to the MME 306/SGSN 308. The MME 306/SGSN 308 may try a different P-GW/GGSN before sending the rejection to the UE 202.
The MME 306 (SGSN 308) restricts the load that its eNodeBs (BSC/RNC) are generating on it, if it is configured to enable the overload restriction. Particularly, the MME 306 (SGSN 308) can request the eNodeB (BSC/RNC) to restrict the load from certain categories of MTC devices. In response, the eNodeB (RNC) may reject RRC connection requests and indicate to the UE 202 a back-off timer value to limit further RRC connection requests. The UE 202 can provide a low access priority indication to the MME 306/SGSN 308 via NAS signaling. This will allow the MME 306/SGSN 308 to command the UE 202 to move to a state where it does not need to generate further signaling messages and/or does not reselect the PLMN.
As indicated in clause 4.4.12 of TS 23.401 (and clause 5.4.11 of TS 23.060 for UTRAN), the RAN Congestion Awareness Function (RCAF 504) collects information related to user plane congestion from the RAN's OAM system based on which the RCAF 504 determines the congestion level (and the identifier) of an eNB or E-UTRAN (UTRAN) cell. The RCAF 504 is included in the Policy and Charging Control (PCC) Architecture, as shown in FIG. 5 (copied from TS 23.203). Also, the RCAF 504 is assumed to serve a geographical area, as indicated in clause 6.1.15.3 of TS 23.203.
Via the Nq/Nq′ interface, the RCAF 504 determines the UEs served by a congested eNB or congested E-UTRAN cell and retrieves the APNs of the active PDN connections of those UEs. A recent Rel-13 work item just started to define the application protocol over the Nq reference point (Nq-AP), and its results will be included in TS 29.405 Nq and Nq′ Application Protocol (Nq-AP); Stage 3. Via the Np reference point, the RCAF 504 sends the RAN User Plane Congestion Information (RUCI) to the PCRFs serving the UEs' PDN connections. A recent Rel-13 TS 29.217 “Policy and Charging Control: Congestion Reporting over Np Reference Point” describes the Np messages and Diameter AVPs.